In the last several days, I've written
VCfs - an svn/svk/foo wrapper for local operations
list.pm - OO list methods
svn_rcopy - http -> http svm
cwd_proc - find procs working in (or with open fds in) a given directory
svn_lifespan - pull first and last checkin dates from logs
add_copyright - slap a # Copyright ... entry on line 3 (needs salt)
And probably some others that I can't quite think of, but I'm finally getting my svn, module-starter, and other practices to the point where I could write a program to pull the svn logs and tell me exactly what .pm and bin/ files were added in the last N days and then grab the "name - description" bit out of the pod to make the above into a little more automatic summary. And, I did finally move some well-worn code utilities out of my private stash into the svn/code_utilities/ dir, but what I really need is a pre-cpan staging area where these tools can live until they grow up.
And all of this is in pursuit of some kind of ideal platonic pattern for code development which imposes very little overhead at the beginning (so that I'll actually use it) and at the same time makes it easy to grow through those next stages of review, revision, and publication. It's worth noting that this is the itch that led me to believe that ruby might be the way to go (i.e. I tend to recognize trouble in growing a hack into an engineered solution and thought that using a language which forces engineering up-front would do the trick) -- but the growing pains are IN THE PROCESS, so switching to an overly rigorous language is just a knee-jerk reaction. Besides, perl still has better technology and I don't even want to discuss rubygems.
The latest thought involves something of an "svn propset release:type perl5/module ./" with various types like perl5/hack, ruby/hack, etc. Maybe I'll eventually find a continuous integration system that all of these bits will fit into. For now, I'm just trying to get my directory structures normalized and some Build.PL files in the right places. The latest normalization / migration challenge being CAD::Drawing, which does need about 6 different dists because of the plugins, but definitely 17 was a bad idea.
But then there's this question of what to do about the PerlTestJuggler. Should it be symlinks of 01-foo.t -> foo.pl or vice-versa? The current setup has the foo.pl checked-in, but that means you have to get the ptj if you're going to run my tests as checked-out. Going the other direction means quite a bit more work in ptj and doesn't allow me to promote .pl's to .t's at my leisure (without really forcing the ptj workflow into a bonsai kitten shape) but works better for windows users checking-out.
Oh, and at some point I ran awstats.pl and bits of dirvish through a few of the B:: modules. Try it. Now to just hack together something between that and PPI to modularize this sort of 10kloc flatfile...
